Secure and efficient application monitoring and replication

Memory corruption vulnerabilities remain a grave threat to systems software written in C/C++. Current best practices dictate compiling programs with exploit mitigations such as stack canaries, address space layout randomization, and control-flow integrity. However, adversaries quickly find ways to circumvent such mitigations, sometimes even before these mitigations are widely deployed. In this paper, we focus on an "orthogonal" defense that amplifies the effectiveness of traditional exploit mitigations. The key idea is to create multiple diversified replicas of a vulnerable program and then execute these replicas in lockstep on identical inputs while simultaneously monitoring their behavior. A malicious input that causes the diversified replicas to diverge in their behavior will be detected by the monitor; this allows discovery of previously unknown attacks such as zero-day exploits. So far, such multi-variant execution environments (MVEEs) have been held back by substantial runtime overheads. This paper presents a new design, ReMon, that is non-intrusive, secure, and highly efficient. Whereas previous schemes either monitor every system call or none at all, our system enforces cross-checking only for security critical system calls while supporting more relaxed monitoring policies for system calls that are not security critical. We achieve this by splitting the monitoring and replication logic into an in-process component and a cross-process component. Our evaluation shows that ReMon offers same level of security as conservative MVEEs and run realistic server benchmarks at near-native speeds

Selfrando: Securing the Tor Browser against De-anonymization Exploits

Abstract Tor is a well-known anonymous communication system used by millions of users, including journalists and civil rights activists all over the world. The Tor Browser gives non-technical users an easy way to access the Tor Network. However, many government organizations are actively trying to compromise Tor not only in regions with repressive regimes but also in the free world, as the recent FBI incidents clearly demonstrate. Exploiting software vulnerabilities in general, and browser vulnerabilities in particular, constitutes a clear and present threat to the Tor software. The Tor Browser shares a large part of its attack surface with the Firefox browser. Therefore, Firefox vulnerabilities (even patched ones) are highly valuable to attackers trying to monitor users of the Tor Browser. In this paper, we present selfrando-an enhanced and practical load-time randomization technique for the Tor Browser that defends against exploits, such as the one FBI allegedly used against Tor users. Our solution significantly improves security over standard address space layout randomization (ASLR) techniques currently used by Firefox and other mainstream browsers. Moreover, we collaborated closely with the Tor Project to ensure that selfrando is fully compatible with AddressSanitizer (ASan), a compiler feature to detect memory corruption. ASan is used in a hardened version of Tor Browser for test purposes. The Tor Project decided to include our solution in the hardened releases of the Tor Browser, which is currently undergoing field testing

Securing Statically and Dynamically Compiled Programs using Software Diversity

Code-reuse attacks are notoriously hard to defeat, and many current solutions to the problem focus on automated software diversity. This is a promising area of research, as diversity attacks one cause of code reuse attacks—the software monoculture. Software diversity raises the costs of an attack by providing users with different variations of the same program. However, modern software diversity implementations are still vulnerable to certain threats: code disclosure attacks and attacks targeted at JIT (just-in-time) compilers for dynamically compiled languages.In this dissertation, we address the pressing problem of building secure systems out of programs written in unsafe languages. Specifically, we use software diversity to present attackers with an unpredictable attack surface. This dissertation contributes new techniques that improve the security, efficiency, and coverage of software diversity. We discuss three practical aspects of software diversity deployment: (i) performance optimization using profile guided code randomization, (ii) transparent code randomization for JIT compilers, and (iii) code hiding support for JIT compilers. We make the following contributions: we show a generic technique to reduce the runtime cost of software diversity, describe the first technique that diversifies the output of JIT compilers and requires no source code changes to the JIT engine, and contribute new techniques to prevent disclosure of diversified code. Specifically, we demonstrate how to switch between execute-only and read-write page permissions to efficiently and comprehensively prevent JIT-oriented exploits.Our in-depth performance and security evaluation shows that software diversity can be efficiently implemented with low overhead (as low as 1% for profile-guided NOP insertion and 7.8% for JIT code hiding) and is an effective defense against a large class of code reuse and code disclosure attacks

Thwarting Cache Side-Channel Attacks Through Dynamic Software Diversity

Abstract—We explore software diversity as a defense against side-channel attacks by dynamically and systematically random-izing the control flow of programs. Existing software diversity techniques transform each program trace identically. Our di-versity based technique instead transforms programs to make each program trace unique. This approach offers probabilistic protection against both online and off-line side-channel attacks. In particular, we create a large number of unique program execution paths by automatically generating diversified replicas for parts of an input program. Replicas derived from the same original program fragment have different implementations, but perform semantically equivalent computations. At runtime we then randomly and frequently switch between these replicas. We evaluate how well our approach thwarts cache-based side-channel attacks, in which an attacker strives to recover cryp-tographic keys by analyzing side-effects of program execution. Our method requires no manual effort or hardware changes, has a reasonable performance impact, and reduces side-channel information leakage significantly. I

Block Oriented Programming: Automating Data-Only Attacks

With the widespread deployment of Control-Flow Integrity (CFI), control-flow hijacking attacks, and consequently code reuse attacks, are significantly more difficult. CFI limits control flow to well-known locations, severely restricting arbitrary code execution. Assessing the remaining attack surface of an application under advanced control-flow hijack defenses such as CFI and shadow stacks remains an open problem.We introduce BOPC, a mechanism to automatically assess whether an attacker can execute arbitrary code on a binary hardened with CFI/shadow stack defenses. BOPC computes exploits for a target program from payload specifications written in a Turing-complete, high-level language called SPL that abstracts away architecture and program-specific details. SPL payloads are compiled into a program trace that executes the desired behavior on top of the target binary. The input for BOPC is an SPL payload, a starting point (e.g., from a fuzzer crash) and an arbitrary memory write primitive that allows application state corruption. To map SPL payloads to a program trace, BOPC introduces Block Oriented Programming (BOP), a new code reuse technique that utilizes entire basic blocks as gadgets along valid execution paths in the program, i.e., without violating CFI or shadow stack policies. We find that the problem of mapping payloads to program traces is NP-hard, so BOPC first reduces the search space by pruning infeasible paths and then uses heuristics to guide the search to probable paths. BOPC encodes the BOP payload as a set of memory writes.We execute 13 SPL payloads applied to 10 popular applications. BOPC successfully finds payloads and complex execution traces which would likely not have been found through manual analysis - while following the target's Control-Flow Graph under an ideal CFI policy in 81% of the cases

Return to Where? You Can't Exploit What You Can't Find

Detecting and preventing exploitation of memory corruption vulnerabilities is highly challenging. Until now, no countermeasure has been able to fully prevent sophisticated exploitation techniques, such as return-oriented programming (ROP). Recent control-flow integrity (CFI) defenses from Google and Microsoft can be bypassed by constructing a ROP payload that adheres to the control-flow constraints or by exploiting implementation flaws. Microsoft's EMET has less overhead than full CFI, but offers less protection in return, and can be bypassed. Probabilistic countermeasures based on memory layout randomization (such as ASLR) are already in widespread use. However, the Pwn2own competitions have repeatedly demonstrated that attackers can bypass code randomization using memory leaks in browsers. To reduce the impact of memory disclosure, recent defenses utilize execute-only memory. In this work we show that execute-only memory is insufficient and that these solutions can still be bypassed. In particular, we show how to determine the code layout by analyzing pointers in the heap and on the stack without ever reading the code. On the defensive side, we build a comprehensive yet practical defense called Readactor that counters both direct reading of code and indirect layout disclosure through analysis of code pointers. We employ a thin hypervisor and a kernel patch to utilize true hardware execute-only memory, and prevent direct reading of code in Linux processes. We hide all code pointers in readable memory using a patched version of the LLVM compiler. We deploy a number of techniques to break ROP gadget chains and disorient the adversary. Specifically, we hide code pointers by converting them into direct jumps stored in execute-only memory to prevent indirect layout disclosure. Our solution is efficient, because it activates previously unused hardware capabilities in modern x86 processors and is often faster than industry CFI implementations. Our solution is also highly practical; we were able to automatically apply our defense to the Chromium web browser. Finally, our solution is comprehensive; we also protect the dynamically generated code emitted by the V8 JavaScript JIT compiler